wafer.space Community
📐 - Designing / 📝-project-template
Between 2025-11-30 11:59 p.m. and 2026-01-01 12:00 a.m.
.sdc in the template has this at the end:
if { [info exists ::env(OPENLANE_SDC_IDEAL_CLOCKS)] && $::env(OPENLANE_SDC_IDEAL_CLOCKS) } {
unset_propagated_clock [all_clocks]
} else {
set_propagated_clock [all_clocks]
}
However I've instrumented this and that variable is never set in any stages, which is probably why I have multi-hundred-ns clock slew times in pre-CTS STA. @Leo Moser (mole99) do you know what's up with that? librelane sets it here: https://github.com/librelane/librelane/blob/774d6e6f221ccf21bd499e9b8ccba4afeffff4fd/librelane/steps/openroad.py#L725-L728
unset_propagated_clock is supposed to do:
right now there isn't really any usable timing information in the early STA which I imagine is part of the reason the early resizer step has been turned off 0.150000 0.000000 0.000000 clock clk_PAD (rise edge)
0.000000 0.000000 clock network delay (ideal)
0.150000 0.000000 0.000000 ^ i_chip_core.tt.i_peripherals.i_simple_peri16.i_spi_ctrl.rstn_gf180mcu_fd_sc_mcu7t5v0__dffq_1_Q/CLK (gf180mcu_fd_sc_mcu7t5v0__dffq_1)
832 4.638381 110.209221 63.362564 63.362564 ^ i_chip_core.tt.i_peripherals.i_simple_peri16.i_spi_ctrl.rstn_gf180mcu_fd_sc_mcu7t5v0__dffq_1_Q/Q (gf180mcu_fd_sc_mcu7t5v0__dffq_1)
i_chip_core.tt.i_peripherals.i_simple_peri16.i_spi_ctrl.rstn (net)
110.209221 0.000000 63.362564 ^ i_chip_core.tt.i_peripherals.i_simple_peri19.ay8913.noise_generator.reset_gf180mcu_fd_sc_mcu7t5v0__clkinv_1_ZN/I (gf180mcu_fd_sc_mcu7t5v0__clkinv_1)
164 0.691456 3.280350 53.123268 116.485832 v i_chip_core.tt.i_peripherals.i_simple_peri19.ay8913.noise_generator.reset_gf180mcu_fd_sc_mcu7t5v0__clkinv_1_ZN/ZN (gf180mcu_fd_sc_mcu7t5v0__clkinv_1)
i_chip_core.tt.i_peripherals.i_simple_peri19.ay8913.noise_generator.reset (net)
1set main_clk_pin [get_pins i_chip_core.clkroot_sys_u.magic_clkroot_anchor_u/Z]
set rst_pins [get_pins i_chip_core.*sync*flop2/Q]
set clk_pins [get_pins -of_objects [get_net -of_objects ${main_clk_pin}]]
set clk_loads [llength ${clk_pins}]
puts "clk_sys has ${clk_loads} directly connected pins"
if { [expr $clk_loads > 10] } {
puts "Setting all clocks to ideal!"
unset_propagated_clock [all_clocks]
puts "Case analysing reset nets:"
foreach pin ${rst_pins} {puts [sta::get_full_name ${pin}]}
set_case_analysis 1 ${rst_pins}
} else {
puts "Setting all clocks to non-ideal"
set_propagated_clock [all_clocks]
unset_case_analysis ${rst_pins}
}
Seems to work for me. Might give better placement as the datapath delays are actually realistic. 2
AREA 3 seems to be working best/fastest for my design so farlibrelane-explore: ## Run synthesis exploration
librelane librelane/config.yaml --pdk ${PDK} --pdk-root ${PDK_ROOT} --manual-pdk --last-run --flow SynthesisExploration
.PHONY: librelane-explore
And then run make librelane-explore it will try all 9 strategies and tell you which is best (though it's just synthesis timing)
2
2
got it down to about 3ns but just can't seem to improve from there. might need to just drop the clock at this point 1
1
looked fine in the normal corners, just the hot ones were bad
1 I'm using a transpiled HDL which makes everything even more inscrutable too
RUN_POST_GRT_RESIZER_TIMING: True 
yaml before config.yaml broke 9t cell support! 
resloved.json in the runs folder gets confused
yaml file passed into the librelane 
♂️
yaml before config.yaml broke 9t cell support! STD_CELL_LIBRARY to slot_*.yaml instead is a workaround.
I'm suspect that only STD_CELL_LIBRARY is affected because it is a special variable that can be set by passing --scl to LibreLane. If you see other variables being overwritten, please let me know. However, I think that's unlikely.STD_CELL_LIBRARY to slot_*.yaml instead is a workaround.
I'm suspect that only STD_CELL_LIBRARY is affected because it is a special variable that can be set by passing --scl to LibreLane. If you see other variables being overwritten, please let me know. However, I think that's unlikely. 1
1 1SYNTH_AUTONAME: True, however that results in very long names so you'll likely have to go up to Magic 8.3.578 or later to avoid LVS errorsRUN_POST_GRT_RESIZER_TIMING: True 3
1config.json from the CTS pass:
"CTS_CLK_MAX_WIRE_LENGTH": 0,
Would limiting the max wire length help with the pre/post extraction differences? 1 3
it works!
4
2
3
4 1config.json from the CTS pass:
"CTS_CLK_MAX_WIRE_LENGTH": 0,
Would limiting the max wire length help with the pre/post extraction differences? CTS_CLK_MAX_WIRE_LENGTH only constraints the wire from the clock input pin to the clock root buffer. So it would only shift the whole clock tree, as I understand it. 1
1CTS_CLK_MAX_WIRE_LENGTH only constraints the wire from the clock input pin to the clock root buffer. So it would only shift the whole clock tree, as I understand it. 
1CTS_DISTANCE_BETWEEN_BUFFERS seems to do nothing at all 1CTS_TOLERANCE from OpenLANE was removed 
1
1
1 1 1 1
Chip' - Stage 68 - Design Rule Check (KLayout) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸━━━━━ 67/77 7:51:20
I am having a time of it 1
1
1
2 1
Chip' - Stage 68 - Design Rule Check (KLayout) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸━━━━━ 67/77 7:51:20
I am having a time of it Chip' - Stage 68 - Design Rule Check (KLayout) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸━━━━━ 67/77 11:45:25
um. what do I do when klayout gets stuck on my design.
Chip' - Stage 68 - Design Rule Check (KLayout) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸━━━━━ 67/77 11:45:25
um. what do I do when klayout gets stuck on my design. 
time to learn how to debug...hopefully it's just the logo art I added 
Poly overlap of contact < 0.065um (CO.3) in 9-track std cells gf180mcuD pdk,
co3_l.output('CO.3', 'CO.3 : Poly2 overlap of contact. : 0.07µm')
Does wafer.space have it's own version of the pdk? 
1
1
But you also need to pass the initial state. probably easiest to just redo the whole thing, the DRC is the timesuck anyway and that cant be avoided 1 )
1
1DF.6_MV : Min. COMP extend beyond gate (it also means source/drain overhang). : 0.4µm.
COMP on top belongs to a sdffrnq_4 and poly below belongs to a nand3_4 
1DF.6_MV : Min. COMP extend beyond gate (it also means source/drain overhang). : 0.4µm.
COMP on top belongs to a sdffrnq_4 and poly below belongs to a nand3_4 
sdffrnq_4 in the future https://github.com/Wren6991/RISCBoy-180/blob/main/librelane/gf180_scanflop_map.v 2 1sdffrnq_4 in the future https://github.com/Wren6991/RISCBoy-180/blob/main/librelane/gf180_scanflop_map.v 
1
1
as a complete outsider to the industry, i'm kinda horrified what passes as normal (from the little bit I've peeked behind the curtain)
1
1 1 * Project: 018 5VGREEN SRAM
* Author: GlobalFoundries PDK Authors
* Data Created: 05-06-2014
* Revision: 0.0 1
librelane-yolo: ## Run full flow, including DRC, but don't quit after DRC errors
librelane librelane/config.yaml --pdk ${PDK} --pdk-root ${PDK_ROOT} --manual-pdk --skip Checker.MagicDRC --skip Checker.KLayoutDRC
.PHONY: librelane-yolo 1
1
2 2 1
4--noextract option which will use the existing extracted data in the WORK_ROOT directory. 
1
1 1 5 /*******************************************************************************
* SRAM_CHICKEN *
*******************************************************************************/
// The foundry SRAM models return incorrect data if chip select transitions on a
// clock edge. 99% sure this is just an issue with the model, but just in case,
// this register forces all SRAMs to be permanently enabled. You should clear
// this bit to avoid wasting power.
// Field: SRAM_CHICKEN Access: RW
// Reset: 0x1
#define SYSCFG_SRAM_CHICKEN_LSB 0
#define SYSCFG_SRAM_CHICKEN_BITS 1
#define SYSCFG_SRAM_CHICKEN_MASK 0x1
I can simulate with the unmodified foundry models now. When I get chips back I'll find out whether that was necessary. 1 1 I'm going to keep testing up until the last minute 1
4
1
klayout -e is the magic flag required to actually let you edit anything) 1 1 thanks Greg 1
1 1
STD_CELL_LIBRARY: gf180mcu_fd_sc_mcu9t5v0 in the project template and it's not applied (still the 7 track cell). Is this overriden somewhere I'm missing? 1 1
1 3 2
The PDK and project template have been updated with the following changes:
ANTENNAGATEPLUSDIFF in the techlef for thick oxide devices. (thanks @egor!) The PDK and project template have been updated with the following changes:
ANTENNAGATEPLUSDIFF in the techlef for thick oxide devices. (thanks @egor!) 1 3 Major performance update!
A long-standing issue in the KLayout DRC deck has been discovered and fixed
Many thanks to Matthias for investigating the issue and providing a solution.
This reduces the time taken by KLayout DRC for one tested design from several hours to just 1.5h ⏱️
6
2 1
1 3 1
1 1 1
1 1 1 1 Update Time!
The PDK has been updated with changes to the KLayout antenna script.
Update Time!
The PDK has been updated with changes to the KLayout antenna script.
1 @everyone Important Update!
This update introduces a reworked filler generation that complies with several rules that the foundry did not allow us to waive. This may result in your design not meeting the necessary metal density requirements. Therefore, an option has been added to the filler generation script which enables the dummy fill shapes to be moved to the active metal layer, in order to allow some of these very restrictive rules to be ignored.
This option is enabled by default for the Metal2 layer in the project template, as this layer is most likely to be under the minimum density limit for digital designs.
Additionally, the antenna script has been updated to correctly verify the antenna rules according to the PDK docs. Previously, the check did not take the diode area into account correctly. Thanks to @tnt for identifying the issue and to @Egor Lukyanchenko for providing an updated KLayout implementation.
Furthermore, another issue was discovered in the antenna script.
Similar to the DRC deck, the comp layer needs to be cut by the poly gate to prevent shorts in the extracted netlist. This was less obvious than in the DRC deck, since the antenna check starts with the lower layers and progresses to the upper layers. It is expected for the check to get progressively slower - but not to this extent!
The antenna check should now finish in reasonable time, even for very complex designs.
(Previously, one design with a lot of combinatorial logic timed out on the online platform. Now the antenna check for this design completes in 13.7 minutes on my machine.) 5 1
ANTENNADIFFSIDEAREARATIO. 1
@everyone Important Update!
This update introduces a reworked filler generation that complies with several rules that the foundry did not allow us to waive. This may result in your design not meeting the necessary metal density requirements. Therefore, an option has been added to the filler generation script which enables the dummy fill shapes to be moved to the active metal layer, in order to allow some of these very restrictive rules to be ignored.
This option is enabled by default for the Metal2 layer in the project template, as this layer is most likely to be under the minimum density limit for digital designs.
Additionally, the antenna script has been updated to correctly verify the antenna rules according to the PDK docs. Previously, the check did not take the diode area into account correctly. Thanks to @tnt for identifying the issue and to @Egor Lukyanchenko for providing an updated KLayout implementation.
Furthermore, another issue was discovered in the antenna script.
Similar to the DRC deck, the comp layer needs to be cut by the poly gate to prevent shorts in the extracted netlist. This was less obvious than in the DRC deck, since the antenna check starts with the lower layers and progresses to the upper layers. It is expected for the check to get progressively slower - but not to this extent!
The antenna check should now finish in reasonable time, even for very complex designs.
(Previously, one design with a lot of combinatorial logic timed out on the online platform. Now the antenna check for this design completes in 13.7 minutes on my machine.) 
2 1-rd Metaln_active to the script, where n is the number of the metal layer. This moves the fill shapes to the active metal layer and thus ignores some of the dummy fill rules. 1filler to drawing and then run the full precheck on that. 1 1 1 3
1
Metaln_ignore_active. 1
10
I guess at 5V the IR drop isn't all that big a deal but still, not sure if IR Drop stuff is properly setup in the default template. I guess at 5V the IR drop isn't all that big a deal but still, not sure if IR Drop stuff is properly setup in the default template. 1
2 1
1-rd Metal2_ignore_active-rd Metal2_ignore_active 1 1
♂️♂️ 1 1 1 3 1 2♂️ u_sram in my pdn.tcl 1u_chip_core.gen_proc_wrapper[<instance_number>].u_proc_wrapper.u_sram blocks[ ], but escaping them stopped them matching anything 2 1 2 1 One More Update!
No worries - if your design passed precheck before, it will pass precheck now, too.
This update makes magic DRC optional: magic DRC violations won't block the submission process.
This decision was made due to a number of false positive errors that can show up if you read in a layout in magic that was not generated by magic.
However, please note that you should still closely verify all magic DRC violations. If you have any doubts, or magic catches a DRC violation that KLayout does not, please let us know.
The other change is that the antenna check will also consider nwell-to-pcomp diodes. Previously, it only considered pcomp-to-nwell and nplus-to-substrate diodes.
These structures are found inside the foundry-provided I/O cells, so this change should help reduce antenna violations in some cases.
PS: Another reminder to submit your designs @ https://platform.wafer.space/ by 17th Dec @ 11:59pm AoE❗
And please make sure to update your project description, visibility, license, and URL. 1 1 One More Update!
No worries - if your design passed precheck before, it will pass precheck now, too.
This update makes magic DRC optional: magic DRC violations won't block the submission process.
This decision was made due to a number of false positive errors that can show up if you read in a layout in magic that was not generated by magic.
However, please note that you should still closely verify all magic DRC violations. If you have any doubts, or magic catches a DRC violation that KLayout does not, please let us know.
The other change is that the antenna check will also consider nwell-to-pcomp diodes. Previously, it only considered pcomp-to-nwell and nplus-to-substrate diodes.
These structures are found inside the foundry-provided I/O cells, so this change should help reduce antenna violations in some cases.
PS: Another reminder to submit your designs @ https://platform.wafer.space/ by 17th Dec @ 11:59pm AoE❗
And please make sure to update your project description, visibility, license, and URL. 
1
This tapeout has 13 different projects on it, coming from our students or from our research departments.
Some of our highlights are the game Tetris and a RISC-V CPU for our TinyWhisper project. And of course, our students are excited to tape their first chip.
The starting template has also been extended with some more Makefile targets to also build specific macros, copy important reports 
copy-reports, and copy & ZIP the GDS for submission copy-gds. There is also a Makefile target build-all, which enables everyone to simply clone the repo, install the nix-shell, execute make build-all in it, and the whole chip will be built submission-ready. Maybe this is useful for someone for future runs. Feel free to use it.
A big shoutout to @Leo Moser (mole99), who supported us during this journey. Another thanks to @Tholin and his project (https://github.com/AvalonSemiconductors/ws-submission-2025/), which served as a reference for using macros. Thanks @Tim 'mithro' Ansell and everyone else involved, for making this possible.
GitHub Repo: https://github.com/iic-jku/gf180mcu-jku-projects
7 1
1 8 5 4
2 1
default_nettype wire? 4 2 2 1
1 1
1gf180mcu/flows/chip.py I see a list of steps that are executed for the whole flow. Then in gf180mcu/steps/* all the actual step processing logic and config/parameters lives, correct?
So when you add a OpenROAD.Floorplan step to chip.py, the corresponding logic is defined in the Floorplan(OpenROADStep) class residing in steps/openroad.py Is that the gist of how it works?
context: was investigating adding an optional rtl_macro_placer step to the flow (ala https://github.com/librelane/librelane/issues/537). Placing macros by hand was super tedious for me, and probably terrible layout performance gf180mcu/flows/chip.py I see a list of steps that are executed for the whole flow. Then in gf180mcu/steps/* all the actual step processing logic and config/parameters lives, correct?
So when you add a OpenROAD.Floorplan step to chip.py, the corresponding logic is defined in the Floorplan(OpenROADStep) class residing in steps/openroad.py Is that the gist of how it works?
context: was investigating adding an optional rtl_macro_placer step to the flow (ala https://github.com/librelane/librelane/issues/537). Placing macros by hand was super tedious for me, and probably terrible layout performance PYTHONPATH, and which has a filename which begins with librelane_plugin_rmp you would have nulled out the GlobalPlacement, DetailedPlacement and GlobalRouting , then inserted your RMP to run (and which includes the others)? OpenROAD.RMPPlus afterwards to try to use the information
And even moreso for how parameters interact. optimizing was a lot of tweaking and seeing how it adjusted things ) 1 1 1dffrnq (flop with async reset) are all drive=1. 
1